受動的なチームをどう動かすか。モメンタムを生み出すための実践録

チームのモメンタム（勢い）がない。メンバーが受動的で指示待ちになっている。エンジニアリングマネージャーやテックリードであれば、一度は直面する課題ですよね。

現在ぼくが受け持っているチームも、当初はまさに絵に描いたような受動的なチームでした。 基本的には言われたことだけをやる。与えられたオーダーを消化することがすべて、という状態です。

指示待ちの「レガシーシステム」と化したチーム

当時の定例ミーティングでの確認も、ただのポーリング通信のようになっていました。「進んでますか？」「いや、進んでないです」というステータスコードのやり取りだけで、進んでいない場合は「うーん」と唸るだけ。聞いている側もただ「うーん」と同調し、お互いに傷をなめあうような、何も解決しないデッドロックのような状態に陥っていたんです。

これでは、異常時にただログを吐いて止まるだけの、古いバッチ処理と変わりません。

この状況を打開し、チームにモメンタムを作るために、いくつかのアプローチを実施しました。

アプローチ1：定例ミーティングでのブロッカーの可視化

一つ目は、定例での課題共有の改善です。

単なる進捗のYes/Noを問うのをやめ、「具体的に何に困っているのか」「どういった助けが欲しいのか」を明確にアラートとして上げてもらうようにしました。ボトルネックを可視化しない限り、適切なリソース割り当てやブロッカーの排除はできないからです。

アプローチ2：振り返り（YWT+K）による「ログ出力」と感情の可視化

二つ目は、隔週での振り返りの導入です。 フォーマットは「YWT+K」を採用しました。正直なところ、W（わかったこと）とK（かんじたこと）の部分の切り分けがうまくできていないメンバーもいます。しかし、ここでの目的は厳密なフォーマットへの準拠ではなく、個人の状態のログ出力です。 言語化を促すことで、「どんな感情でタスクに取り組んでいたのか」「事実としてわかったことは何なのか」が可視化されるようになりました。

ここで出たログの中で、特に「感情的にも困っていそうなこと」は、システムにおけるクリティカルなアラートと同等と見なし、チームとして取り組まないといけない度合いが強い題材として優先度を上げて扱うようにしました。

また、エラーやアラートだけでなく、「やってよかったこと」やポジティブな感情もログに現れるようになったのは、これまでになかった大きな変化です。うまくいったアプローチは単発の処理で終わらせず、チームのベストプラクティスとしてキャッシュし、継続して実行すべきものとして扱えるようになりました。

これを続けていくうちに、いつしか自分たちで書き出したリストの中から「ここが気になる」「これは続けよう」と自発的にトピックをピックアップしてくれるようになったんです。監視ダッシュボードを見て、自律的に対応や改善を始めるような嬉しい変化です。

アプローチ3：具体的なDiffに対する「Approve」の明示

三つ目は、具体的な行動に対するフィードバックループの構築です。 日々の行動から、良かったことやチームに貢献してくれたことを明言するようにしました。

ここで重要なのは、ただ単に「すごいね」「頑張ったね」とふわっと褒めるのは明確なアンチパターンだということです。 そうではなく、「あのPRのコメントでの有意義な指摘や提案に助けられた」「Slack上でのあのやり取りは非常に良かった」など、具体的な差分（Diff）に対して明確にApproveの意を伝えるようにしました。

結果：主体性の向上と、継続的な最適化へ

これらのアプローチを続けた結果、チームの振る舞いは明らかに変化しました。 以前の受動的だった状態から、主体的な行動が目に見えて増えていったんです。

今現在、チームとしてはまだまだ最適化の余地（伸びしろ）はある状態です。しかし、モメンタムとしては非常に良い状態にあると評価しています。

この良い状態の基盤があるからこそ、マネージャーとして見ている問題や、新たに設定している課題をチームに投げかけた際も、みんなが前向きに解決策を考えてくれるようになっています。

モメンタムという抽象的な概念も、日々のコミュニケーションのプロトコルを見直し、適切なフィードバックと可視化を繰り返すことで、着実に構築していくことができます。